Here, it means this is a DV profile 10.0 content, which is not backward compatible to AV1 so that it cannot be played as AV1 content on non-Dolby licensed device.
Instead, DV profile 10.1 and 10.4 can be played as AV1 content on non-Dolby licensed device.
See more details on https://professionalsupport.dolby.com/s/article/What-is-Dolby-Vision-Profile?language=en_US, table 2.

@ybai001
Do DV profiles 10.1 and 10.4 not have these color space values? Or your solution is to only set these values for 10.0 and using that fact to make sure its not backwards compatible?

If other DV profiles have these color space values then its not a robust solution. What if in the future that information is generally parsed for all DolbyVision streams for some other purpose? Is there any other way to know the cross-compatibility id?

@microkatz, we actually set these values for other profiles here.

Let me provide more info about this code change.

Dolby Vision profile 10 includes profile 10.0, 10.1 and 10.4 currently. P10.0 is not backward-compatible with AV1 and cannot be played on non-Dolby licensed device while P10.1 and P10.4 can. The purpose of this piece of code is to return null for P10.0 and to return MimeTypes.VIDEO_AV1 for P10.1 and 10.4.

This method (getAlternativeCodecMimeType()) is called in both track selection and codec selection phase.

During track selection phase, the input is manifest file. CCID is not explicitly indicated in manifest file. The only method is to calculate it based on supplementalCodecs and supplementalProfiles (Since neither supplementalCodecs nor supplementalProfiles is the member of Format structure, we set ColorInfo at first then conclude the CCID based on it).

During codec selection phase, the input includes MPEG4 box info. CCID can be get directly by parsing Format::initializationData.

As a common method in both track selection and codec selection phase, we adopted the ColorInfo method in this PR.

I agree it is not a perfect solution. In future, maybe we need to update getColorInfoForFormat() method to adapt new Dolby Vision profile definitions.

@ybai001

CCID is not explicitly indicated in manifest file. The only method is to calculate it based on supplementalCodecs and supplementalProfiles (Since neither supplementalCodecs nor supplementalProfiles is the member of Format structure, we set ColorInfo at first then conclude the CCID based on it).

Just to clarify, you said that "CCID is not explicitly indicated in the manifest file" but you can interpret it through the supplementalCodecs and supplementalProfiles data? Or more specifically if the codecs string starts with dav1 then it is 10.0 and not 10.1/10.4?

I don't think only setting the ColorInfo for these specific cases is a robust solution. It may be in the future that we need to set this data for the other profiles as well.

Is there any other difference between 10.0, 10.1 & 10.4 that we can use? If we are able to identify the profile characteristic from the manfiest and there is not another value in Format that we can set, then we might need to add a value to Format.

@microkatz

Just to clarify, you said that "CCID is not explicitly indicated in the manifest file" but you can interpret it through the supplementalCodecs and supplementalProfiles data? Or more specifically if the codecs string starts with dav1 then it is 10.0 and not 10.1/10.4?

Right.

Is there any other difference between 10.0, 10.1 & 10.4 that we can use? If we are able to identify the profile characteristic from the manfiest and there is not another value in Format that we can set, then we might need to add a value to Format.

Based on the current "format" structure, this is no other reliable parameter we can use. This is has been reviewed by our Dolby Vision architecture team. ColorInfo is a reliable method since its difference has been declared in Dolby Vision specification document. I actually discussed with Dolby Vision architecture team about adding supplementalCodecs and supplementalProfiles into "format" structure but they didn't suggest me to do it in that way. There is an internal discussion about whether adding a new field in manifest to indicate CCID directly but there is no timeline when decision is done. Since DV profile 10 content creation tool/code has already been delivered to customs, we have to make AndroidX Media support this profile now. The method in this PR is a solution after Dolby internal discusssion.